home *** CD-ROM | disk | FTP | other *** search
/ Languguage OS 2 / Languguage OS II Version 10-94 (Knowledge Media)(1994).ISO / gnu / objcissu.lha / runtime-origins < prev    next >
Internet Message Format  |  1993-03-01  |  11KB

  1. Date: Wed, 19 Aug 92 12:13:06 EDT
  2. From: trirex!dglattin@uunet.UU.NET
  3. To: uunet!marble.com!gsk@uunet.UU.NET
  4. Subject: FSF & Objective C
  5.  
  6. Hi.  Recently I talked with Richard Stallman.  He told me you had some interest in the FSF's Objective C compiler.
  7.  
  8. You may be aware that the FSF's compiler does not contain a run time library.  I wrote one and donated it to the FSF.  It still requires some work but does make the objects go.  It is modeled after NeXT's (2.2) run time and is equal in speed.  I have volunteered to be the FSF's Objective C anything person.
  9.  
  10. Are you interested in this and, who are you?
  11.  
  12. ---
  13. Dennis P. Glatting
  14. Sr. Technical Manager
  15. Trirex Systems Inc.
  16. 315 Post Road West
  17. Westport, Connecticut   06880
  18. 203-221-4614
  19. 203-221-4602 (fax)
  20. dennis_glatting@trirex.com
  21. NeXTmail Ok.
  22.  
  23. Newsgroups: comp.sys.next.misc
  24. From: mmelling@Trirex.com(Michael Mellinger)
  25. Subject: Re: Do you want free objects from FSF?
  26. Organization: Trirex Systems Inc.
  27. Date: Mon, 24 Aug 1992 04:10:37 GMT
  28.  
  29. In article <59776@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:
  30. > In article <Bt8A6G.JuI@world.std.com> gsk@world.std.com (Geoffrey S  
  31. Knauth) writes:
  32. > > Would you like to see free objects, libraries, palettes, toolkits,
  33. > > etc., from the Free Software Foundation?
  34. > Its a great idea that would benefit the whole community, including
  35. > app developers and NeXT Inc.  There is a an unsatisfied precondition  
  36. though.
  37. > The Free Object Foundation needs a FSF Objective C runtime for gcc.
  38. > Is anyone working on one?
  39.  
  40. Yes, Dennis Glatting an employee here at Trirex wrote one.  It will be on  
  41. the NeXT educational CD ROM.  Hopefully, Trirex will be donating more  
  42. objects, utilities, etc. to the NeXT community.  In fact, Dennis is hard  
  43. at work on a Find object that supports regular expressions.  He's not  
  44. screaming as much as he was early this evening, so I think he's making   
  45. progress. :-)
  46.  
  47. -Mike
  48.  
  49. Newsgroups: comp.lang.objective-c
  50. From: dglattin@trirex.com (Dennis Glatting)
  51. Subject: Re:  PD Implementation?
  52. Date: Thu, 27 Aug 1992 20:56:58 GMT
  53.  
  54. In article <alain.3266@charpe.UUCP> alain@charpe.UUCP (Alain Charpentier)  
  55. writes:
  56. >      His anybody aware of some one work on the runtime for GNU.
  57. >      And to they need help.
  58.  
  59. Yes.
  60.  
  61. A Objective C run time has been donated to the Free Software Foundation.   
  62. It includes the dispatcher and Object class.  The run time is portable and  
  63. equivalent in speed to the dispatcher found in NeXT's OS2.2 (overhead of  
  64. 3). 
  65.  
  66. There is some clean up work I need to do to the initialization code and  
  67. some minor changes to the compiler.  At the moment I'm under a time  
  68. crunch.  Soon, soon, ...
  69.  
  70. --
  71. Dennis P. Glatting / Sr. Technical Manager / Trirex Systems Inc.
  72. 315 Post Road West / Westport, Connecticut 06880 / (203)221-4600
  73. dennis_glatting@trirex.com (NeXTmail Ok)
  74. Member League for Programming Freedom
  75.  
  76. Date: Thu, 3 Sep 92 00:06 PDT
  77. From: michael@stb.info.com (Michael Gersten)
  78. To: ucla-cs!marble.com!gsk@cs.ucla.edu
  79. Subject: Obj C system
  80.  
  81. The real question is not, is the performance comparable to Next's objective C. The real question is, is it compatible.
  82.  
  83. Will it support pose as, dynamic loading, etc.
  84.  
  85. Will it be possible to send remote messages between a gnu obj C and a Next obj C program?
  86.  
  87. Will it be possible to take a .o file produced by the next obj C compiler, and dynamic load it into a gnu obj C program? Visa/versa?
  88.  
  89. Is it thread safe, or can it be told to be thread safe? (The issue here is updating the method cache when a new method is added. Next 2.0, for example, is not thread safe, but 3.0 can be told to enable locking (it is off by default).)
  90. --
  91.         Michael Gersten        michael@stb.info.com
  92. HELLO! I'm a signature virus! Join in the fun and copy me into yours!
  93. ex:.-1,. w $HOME/.signature
  94.  
  95. Date: Tue, 8 Sep 92 19:35:33 -0400
  96. From: Dennis Glatting <dglattin@trirex.com>
  97. To: michael@stb.info.com (Michael Gersten)
  98. Subject: Obj C system, questions
  99. Cc: <uunet!marble.com!gsk@uunet.uu.net>
  100.  
  101. > The real question is not, is the performance comparable
  102. > to Next's objective C. The real question is, is it
  103. > compatible.
  104.  
  105. It is compatible in some respests but not others.  For example, posing is supported but forwarding is not.  Archiving objects is supported but types streams are not.  +new is the factory method that creates objects not +alloc.
  106.  
  107. The run time is in its infancy and some of its goals are different than the NeXT or Stepstone implementation.  For example, portability is a key goal.
  108.  
  109. > Will it support pose as, dynamic loading, etc.
  110.  
  111. Posing is supported but dynamic loading is not implemented at this time.  GNU dynamic loading would probably be built upon BFD.  Would you like to write that portion of the package?
  112.  
  113. > Will it be possible to send remote messages between a gnu
  114. > obj C and a Next obj C program?
  115.  
  116. I believe NeXT "remote messages" are based upon Mach messaging and therefore unavailable under SunOS, AIX, etc.  Is your question more of one where you are mixing objects on the same platform or across platforms?
  117.  
  118. > Will it be possible to take a .o file produced by the next
  119. > obj C compiler, and dynamic load it into a gnu obj C
  120. > program? Visa/versa?
  121. >
  122. > Is it thread safe, or can it be told to be thread safe? (The
  123. > issue here is updating the method cache when a new method
  124. > is added. Next 2.0, for example, is not thread safe, but
  125. > 3.0 can be told to enable locking (it is off by default).)
  126.  
  127. Currently the run time is not thread safe but it is planned.  It isn't a difficult thing to do.
  128.  
  129. ---
  130. Dennis P. Glatting / Sr. Technical Manager / Trirex Systems Inc.
  131. 315 Post Road West / Westport, Connecticut 06880 / (203)221-4600
  132. dennis_glatting@trirex.com (NeXTmail Ok)
  133. Member League for Programming Freedom
  134.  
  135. Date: Fri, 18 Sep 92 06:38:07 -0700
  136. From: Dennis Glatting <seattle-ni-srvr!dglattin@trirex.com>
  137. To: Bruce Nilo <uunet!ictv.com!bruce@uunet.uu.net>
  138. Subject: Protocols, Reflection...objc_msgSend()
  139. Cc: gnu-objc@prep.ai.mit.edu
  140.  
  141. > I think that the ability to override objc_msgSend is just
  142. > one aspect of the general desire to be able to specialize
  143. > various runtime behaviors. CLOS provides something
  144. > called the meta object kernel which enables advanced
  145. > programmers to customize the the language itself to the
  146. > point that the default semantics becomes something
  147. > entirely different.
  148.  
  149. How is this different than posing as Object or adding category methods?
  150.  
  151. > A prior suggestion was made that ideally the runtime
  152. > should be object oriented. In my experience this is quite
  153. > doable and, if done, provides a straight forward means to
  154. > override a whole host of behaviors from message dispatch
  155. > to instance variable lookup. Moreover this behavior
  156. > would be customized on a per class basis as opposed to
  157. > globally. New "root" objects could be selectively
  158. > implemented each overriding default low level runtime
  159. > behaviors defined in Object.
  160.  
  161. Origionally, the GNU run time was written in C++.
  162.  
  163. -dpg
  164.  
  165. Date: Fri, 18 Sep 92 06:08:24 -0700
  166. From: Dennis Glatting <seattle-ni-srvr!dglattin@trirex.com>
  167. To: ucla-cs!prep.ai.mit.edu!gnu-objc@cs.ucla.edu
  168. Subject: Re: Automatic input/output, persistence
  169. Reply-To: dennis_glatting@trirex.com
  170.  
  171. > > A key difference between the NeXT and StepStone
  172. > > foundation class libraries is the latter supports a much
  173. > > more convenient scheme for storing objects to and
  174. > > reading them back from files. The NeXT version, as I
  175. > > understand it (I don't have a NeXT; I have a Sun running
  176. > > Stepstone's version), only supports what I would call
  177. > > "semi-automatic" input/output--that is, the
  178. > > implementor of each subclass must implement methods to
  179. > > archive objects of this subclass.  The Stepstone library
  180. > > does not require any new implementation at all.  If your
  181. > > object is a subclass of Stepstone's Object, it
  182. > > automatically inherits Object's hooks automatic
  183. > > input/output--providing you explicitly link in the
  184. > > relevant code.
  185. > >
  186. >
  187. > Doesn't this break the concept of encapsulation?
  188. > Shouldn't the object itself be responsible for what it
  189. > contains and what is relevant rather than an outside
  190. > entity?  How does one automatically store a void*?
  191. >
  192. > -dpg
  193. > ------
  194. > Not at all. Just as every object inherits some default
  195. > behavior, and can override it if they need to, so everyone
  196. > can inherit some default "here's how to write yourself to
  197. > a file" method. If it is really a problem, you can override
  198. > it.
  199.  
  200. Well, that follows the NeXT principals.
  201.  
  202. > Besides, what *CAN* you do with a void? If you mean a void *,
  203. > you'd have to write some special casing, but meanwhile
  204. > you can say [super archive:self] to get the rest of the
  205. > object written, and then just write out whatever your
  206. > void * is pointing to.
  207.  
  208. I did say void*.  What is pointed to by the void* is known only by the class itself and whether it is relevant -- as it should be.  Just as I could say [super archive:self], I can also say [super write:aStream].
  209.  
  210. -dpg
  211.  
  212. Date: Sat, 19 Sep 92 14:09:06 PDT
  213. From: Bruce Nilo <bruce@ictv.com>
  214. To: seattle-ni-srvr!dennis_glatting@uunet.uu.net
  215. Subject: Re: Protocols, Reflection...objc_msgSend()
  216. Cc: gnu-objc@prep.ai.mit.edu
  217.  
  218. >> I think that the ability to override objc_msgSend is just
  219. >> one aspect of the general desire to be able to specialize
  220. >> various runtime behaviors. CLOS provides something
  221. >> called the meta object kernel which enables advanced
  222. >> programmers to customize the the language itself to the
  223. >> point that the default semantics becomes something
  224. >> entirely different.
  225.  
  226. >How is this different than posing as Object or adding category >methods?
  227.  
  228. The runtime behaviors which I am referring to are behaviors which
  229. are not acessible in Object. For example, looking up and setting
  230. instance variables has a well defined semantics in Objective C. However, if I wanted another semantics, say one which added a dynamic versioning capability to instance variable access and mutation, adding category methods or posing as Object would not help me much. The example I referred to above is method invocation. Again if internal runtime behaviors were overridable I could easily define
  231. more involved method dispatch semantics.
  232.  
  233. >> A prior suggestion was made that ideally the runtime
  234. >> should be object oriented. In my experience this is quite
  235. >> doable and, if done, provides a straight forward means to
  236. >> override a whole host of behaviors from message dispatch
  237. >> to instance variable lookup. Moreover this behavior
  238. >> would be customized on a per class basis as opposed to
  239. >> globally. New "root" objects could be selectively
  240. >> implemented each overriding default low level runtime
  241. >> behaviors defined in Object.
  242.  
  243. > Origionally, the GNU run time was written in C++.
  244.  
  245. What I really meant to say was that the runtime could be implemented
  246. meta-circularly. In other words Object could implement the
  247. run time behavior of Objective C via methods defined by Object.
  248.  
  249. Bruce D. Nilo
  250. VP Software Systems
  251. ICTV
  252.  
  253.